Detection of activity patterns

ABSTRACT

A monitoring system (1) comprises an interface (2) for receiving source alerts from at least one detection engine, a database (7) of historical events; and a classifier (3) for classifying received source alerts by linking a source alert with an historical event or a current source alert to provide a link, and providing said link as an output alert. The classifier comprises match methods (9) for processing source alerts and generating a score for extent of matching of a source alert with an historical event or current source alert, a voting engine (4) for weighting scores from the match methods (9), and a linking function (6) for determining that there is a link if a combination of the weighted outputs of a plurality of match methods exceeds a threshold. At least some match methods (9) are each associated with a specific field of a source alert such as a numerical value field or a name field of a source alert. A feedback function (6) notifies a case management system (5) of links, and the voting engine (4) receives from the case management system (5) feedback (11) of success of each match method (9), and adjusts match method weights (12) accordingly.

This is a national stage of PCT/IE08/000030 filed Mar. 27, 2008 andpublished in English, claiming benefit of U.S. provisional applicationNo. 60/920,825, filed Mar. 30, 2007, hereby incorporated by reference.

The invention relates to monitoring of activities such as financialtransaction processing.

Financial service organisations are required to comply with a wide rangeof regulatory requirements related to financial stability, transparentauditing and control, and the detection of money laundering.

As many institutions have millions of customers and process largevolumes of transactions daily, sometimes in the order of millions daily,analysis of the transactions can be onerous.

In addition to compliance requirements, financial services providers arechallenged to deal with an increasing amount of fraud across a number ofchannels. Examples include debit card fraud involving stolen orduplicated cards used to make purchases or obtain cash; mortgageapplication fraud to obtain a loan under false pretences; insuranceclaims fraud involving a claim for a loss that did not occur, or forwhich the loss has been exaggerated; and internal fraud where anemployee or other insider defrauds the organisation. While theproportion of individuals involved in these activities is small, alltransactional and customer activity must be monitored to identifysuspect events and minimise losses due to fraud.

Automated monitoring systems typically have a data acquisition componentto extract the transaction from a source system, transform it into therequired format and load it into the application. In this context, atransaction is taken to mean not only a financial transaction, but alsothe exchange of a unit of information that could be relevant to afinancial crime including the addition of a new customer or theopening/closing of an account. Business rules may be applied by a rulesengine to each transaction. For example, a typical money-laundering ruleis to identify all transactions above a certain threshold. Statisticalor analytical techniques may also be employed to make a decision aboutthe nature of a transaction. For example, the transaction could becompared to a historical average to determine if it is a statisticallysignificant deviation from the norm. If an unusual or suspicious eventoccurs, the rule engine or analysis engine sends an alert message to anexternal system.

GB 2357603B2 describes an approach to detection based on statisticalcomparison of the properties of a transaction with an historicalbaseline. When an unusual transaction occurs, an alert is sent to thesystem operator for investigation.

U.S. Pat. No. 5,819,226 describes the use of a neural network, which isused to determine if an alert should be generated based on an inputpattern of transactions matching the characteristics of a previouspattern of interest.

WO2006/085293A1 describes a real-time rules-based method for transactionmonitoring.

U.S. Pat. No. 6,965,886 describes a real-time analytic engine whichdistributes an alert message for each suspicious event.

Once a detection engine has generated an alert, it is incumbent on theuser to investigate the reason for the alert, and to that endinstitutions have dedicated teams of investigators to investigate eachalert. Parts of the investigation process may be automated within a casemanagement system which manages an investigation through a number ofphases. Typically, this process starts by determining if the alert istruly genuine or a false alarm. If the investigator believes the alertis genuine, the alert is processed through a well-defined sequence ofsteps within a business process or workflow. This may involve thecreation of a case. A case could include for example details of thealert, the entity to which it relates (customer, account, insuranceclaim etc), which transactions contributed to the alert, together withany supporting documentation or notes appropriate to the investigation.The end stage of the workflow could include filing a report with thegovernment regulator, taking steps to counteract fraud (for example bycancelling a credit card) or simply closing the case and leaving it onfile for future reference.

During the preparation of the case, a significant amount of time may bespent searching for and associating alerts from multiple detectionengines involving similar individuals, places, accounts etc. Inaddition, as new alerts occur, they may prove to be linked to a previouscase. As alert message volumes are very large, typically greater than 10million/year for some organisations, the current approach of manualanalysis and linking of alerts is very inefficient. It appears thatbecause exact matching is not possible in many circumstancessatisfactory automated systems have not been developed.

The invention addresses this problem.

SUMMARY OF THE INVENTION

According to the invention, there is provided a monitoring systemcomprising:

-   -   an interface for receiving source alerts from at least one        detection engine,    -   a database of historical events;    -   a classifier for classifying received source alerts by linking a        source alert with an historical event or a current source alert        to provide a link, and providing said link as an output alert,        wherein the classifier comprises:        -   a plurality of match methods for processing source alerts            and generating a score for extent of matching of a source            alert with an historical event or current source alert,        -   a voting engine for weighting scores from the match methods,        -   a linking function for determining that there is a link if a            combination of the weighted outputs of a plurality of match            methods exceeds a threshold.

In one embodiment, at least some match methods are each associated witha specific field of a source alert.

In one embodiment, a match method processes a numerical value field of asource alert.

In one embodiment, a match method processes a name field of a sourcealert.

In one embodiment, a match method processes risk quantifiers in sourcealerts.

In one embodiment, the voting engine is adapted to apply linear ornon-linear functions to determine weights.

In one embodiment, the system comprises a feedback function fornotifying a case management system of links, the voting engine comprisesa function for receiving from the case management system feedback ofsuccess of each match method, and for adjusting match method weightsaccordingly.

In one embodiment, the voting engine initializes a plurality of matchmethod weights to be equal but varies them according to success of theindividual match methods in identifying links.

In one embodiment, said feedback includes a number of false positivesand a number of false negatives.

In one embodiment, the voting engine comprises means for locking scoreregisters so that they can not be simultaneously accessed by more thanone user, thus preserving the integrity of the data in the register

In one embodiment, the system further comprises a timer to periodicallytrigger a process to query the historical event database to extract aset of records which are passed through the classifier, scored by thevoting engine and linked together before being passed to the casemanagement system.

In one embodiment, the timer is adapted to inspect the database andextract a set of grouped events according to search criteria, and theclassifier is adapted to compare a source alert with other members ofthe group using a set of match methods.

In one embodiment, the linking function is adapted to insert a newdatabase record comprising a unique key of the group, and a unique keyfor each linked alert, and a flag to indicate that the alerts arelinked.

In one embodiment, the interface comprises an adapter for normalizingthe source alerts.

In one embodiment, the adapter performs source alert validation.

In one embodiment, the adapter adds data to a source alert.

In one embodiment, the adapter dynamically retrieves data from adatabase to add to a source alert.

In one embodiment, the system comprises means for routing a source alertdirectly to the classifier, by-passing the adapter.

In one embodiment, the system is adapted to instantiate adapter objectsincluding memory buffers to temporarily hold messages until they can beprocessed.

In one embodiment, each adapter object fetches messages from a memorybuffer and executes a set of logical routines on individual fields ofeach source alert to perform validation of fields of the source alert tocheck that they meet quality tests.

In one embodiment, said routines perform transformation of individualsource alert fields into a required format or create additional fieldswhich are combinations of existing fields.

In one embodiment, the system further comprises a configuration functionfor configuring at least one of the components of the system, includingthe classifier.

In one embodiment, the system further comprises a case management systemfor transmitting feedback to the classifier.

In another aspect, the invention provides a computer readable mediumcomprising software code for performing operations of a monitoringsystem defined above when executing on a digital processor.

DETAILED DESCRIPTION OF THE INVENTION

The invention will be more clearly understood from the followingdescription of some embodiments thereof, given by way of example onlywith reference to the accompanying drawings in which:—

FIG. 1 is a schematic illustration of a monitoring system of theinvention; and

FIG. 2 is a schematic illustration of operation of adapters of thesystem and

FIG. 3 is a schematic illustration of a particular adapter;

FIG. 4 is a schematic illustration of a classifier and voting engine ofthe monitoring system;

FIG. 5 is a schematic illustration of the output of the voting engine.

DESCRIPTION OF THE EMBODIMENTS

Referring firstly to FIG. 1, a financial institution has a set of datain its source systems, including for example, customer, account,transaction, policy, or employee information. This information ispresented to one or more detection engines whose purpose is to analysethe data and raise an alert under defined circumstances. Such an enginemay for example be that described in U.S. Pat. No. 6,965,886. Thedetection engines may be devoted to specific business areas, such asanti-money laundering or card fraud, or the same detection engine mayservice more than one business area. Each detection engine is capable ofgenerating an alert which is relayed externally. The alert can be in avariety of forms, for example an e-mail, a new database record, an entryon a message queue, or a text message.

A monitoring system 1 of the invention processes the alerts receivedfrom the external detection systems. It comprises an adapter 2 whichreceives the alerts. It in turn feeds an alert classifier 3, which inturn feeds a voting engine 4. The output of the voting engine 4 feeds alinked alert function 6 which accesses a database 7. The linked alertfunction 6 feeds a case management system 5, which periodically updatesthe voting engine 4, thereby providing a feedback loop. A timer 8periodically triggers a process to query the database 7 to extract a setof records which are passed through the classifier 3, weighted by thevoting engine 4 and linked together before being passed to the casemanagement system 5.

The output of the system 1 is an output alert comprising a linking of asource alert with another source alert or with an historical event. Itis provided by the linked alert function 6. In one embodiment, thelinked alert function inserts a new database record comprising theunique key of the source alert, the unique key(s) of one or more sourcealerts or other incidents and a flag to indicate that the alerts arelinked.

The system 1 is in one embodiment implemented as a set of multipleinstantiated objects which provide parallel processing capability.

Different detection engines may present alert information in differentways. Referring to FIG. 2, in one example a specific alert adapter 13translates incoming alerts so that they contain four fields including aunique identifier, name, date of birth and average transaction size.

The system 1 instantiates adapter objects 2, which serve to standardisethe form of the message. The adapter objects 2 include memory buffers totemporarily hold messages until they can be processed. Each adapterobject 2 fetches messages from the memory buffer and executes a set oflogical routines on the individual fields of each message. Referring toFIG. 3, the adapter objects 2 may perform validation of fields of thealert message to ensure that they meet specific data quality tests;transformation of individual fields into the required format or creationof additional fields which are combinations of existing fields.

The system 1 can also use unique identifiers in the alert to search foradditional information in the source systems or elsewhere. The lattermay for example involve using a unique customer key to retrieve thecustomer's address details from an external database. Search results areappended as sets of additional fields onto the alert message prior tothe classification process. Extension of the alert message in this wayfacilitates a broader range of classification methods to be applied,increasing the accuracy of the classification process. The adapters 2can also generate a unique key for the alert message where none exists.

In those cases where alert information requires no translation, anadapter object 2 is not required.

As shown in FIG. 4, the alert classifier 3 comprises N user-configurablematch methods 9 and associated score-cards 9. Referring also to FIG. 2,it is desired to match the alert labelled with identifier ID10010 torelated historical events using two matching methods. A matching method13 retrieves events with similar names, as shown by an association 14;and a matching method B retrieves historical events with similar averagetransaction size, as shown by an association 15. Two matching incidentswith unique identifiers ID20018 and ID30181 are retrieved, weighted bythe voting engine, and passed to the case management system 5.

The alert classifier 3 parses each alert message and references thedatabase 7 to link the source alert to a current source alert orhistorical event. The current source alerts are stored in memory so thatlinks to them can be determined as well as links to historical eventspersisted in the database 7. The database 7 stores current and archivedevents including both previous output alerts and cases. The classifier 3invokes at run-time a set of methods 9 to match user-defined fields ofthe source alert with user-defined fields of events in the database.Matching techniques include fuzzy text matching to find links based ondescriptive attributes such as name, address, occupation, orquantitative matching such as measurement of Euclidean distance,Mahalanobis distance or similar distance metric applied to numericattributes such as transaction size, transaction frequency or similarvariables. In a financial institution, matching may also be based onrisk, where risk can be a descriptive variable (“low risk”, “high risk”)or a quantitative variable such as loss exposure. For example, onematching method is to cross-check the name field of an alert triggeredby an unusual transaction with the name fields of all other incidents inthe database to determine if the same individual has been identifiedpreviously. Another matching method is to compare a numeric fieldrecording transactional behaviour, such as the average transaction size,with the transaction fields of other incidents to find events with asimilar transactional pattern.

An advantageous aspect of the system 1 is the management of falsepositives (alerts linked in error) and false negatives (alerts shouldhave been linked but were not). Within the case management system 5,users can check the validity of the match as part of the investigationprocess, and also record where a match should have been made but wasnot. User feedback is captured in the voting engine 4, which records thenumber of positive votes (the linking engine 1 matched the alertscorrectly) and negative votes (the linking engine 1 matched the alertsincorrectly, or the linking engine failed to make a match) associatedwith each classification method, based on the decisions made by theusers of the case management system 5. The voting engine 4 is used toupdate the weights 12 associated with each matching method 9. The votingengine 4 may apply a linear or non-linear function of the votes todetermine the appropriate weight 12, so that as each source alert isprocessed the total score is weighted in favour of the most reliablematching methods, improving the accuracy of the matching process. Thisresults in a continuous improvement in the accuracy of the matchingmethods 9. It is an advantage of the system 1 that the user is notrequired to be a technical expert skilled in the design of matchingrules, but that the matching rules are updated by user actionindirectly.

Referring again to FIG. 4, each match method 9 has an associated score10, where the value of the score indicates the likelihood of a truematch. A total score is determined by combining individual scores usinga linear function such as linear polynomial expression of the individualscores or a non-linear function such as simply maximum of the individualscores. The feedback loop acts to vary the initial weights in accordancewith measures of performance of each match method as received from thecase management application.

The voting engine 4 weights each contributing matching score 10 with itsindividual weight 12. The weights are stored in the voting engine 4 andare themselves a function of the number of votes 1 associated with thatmatching method. The total score is then compared to a threshold. If thethreshold is exceeded, the alert is linked to an existing event in thedatabase 7. This is accomplished by updating the event record in thedatabase 7 with the details of the linked source alert. If no link isfound, the source alert is forwarded directly to the case managementsystem 5. If one or more links are found, the new alert is forwarded tothe case management system together with details of the links. Scoringfunctions and thresholds are stored in a database 7, and are used toparameterise run-time objects in memory when the voting engine 4 isinstantiated.

The voting engine 4 maintains a register 11 of the performance of eachof the classifier's matching methods 9. The register 11 is maintained inmemory to maximise performance, and is periodically persisted to thedatabase 7. In the example shown in FIG. 2, there are two votingcategories for positive and negative user comment, however the number ofvoting categories is not restricted, but is preferably at least two. Thevoting engine 4 uses locking so that the registers 11 can not besimultaneously accessed by more than one user, thus preserving theintegrity of the data in the register 11. In the example illustrated inFIG. 4, Match Method A outperforms the other two methods in terms ofsuperior accuracy based on user feedback captured automatically duringcase management. Therefore, in future alert linking, this method willreceive a relatively greater weighting.

FIG. 5 shows the evolution of the weights 12 associated with eachmatching method in a sample of events that were monitored. Both methodsinitially have identical weights, but as the quality of linked incidentsis continuously recorded by the voting engine 4 Match Method A proves tobe superior, and has a relatively higher weighting.

It is an advantage of the invention that the system 1 can identifypatterns which are not event-driven. Indeed the system 1 may identifypatterns which involve absence of expected events.

Periodically, the timer (8) inspects the database (7) and extracts a setof grouped incidents according to user-defined search criteria, forexample based on date. Each incident is processed sequentially throughthe classifier (3) and compared to all other members of the group usinga set of match methods (9) which may be variations of the match methodsused when each alert was processed in an event-driven mode. Should theclassifier find links, the linked alert function inserts a new databaserecord comprising the unique key of the group, the unique key(s) of thelinked alerts or other incidents and a flag to indicate that the alertsare linked.

It will be appreciated that the invention provides for comprehensivemonitoring of activity involving presence or absence of events. It canthus detect complex activities, such as complex fraud situations orengineering plant fault diagnosis.

The invention is not limited to the embodiments described but may bevaried in construction and detail.

The invention claimed is:
 1. A fraud linking system for identifyinglinks between determined fraud events detected in external systems, eachexternal system having at least one fraud detection engine, the fraudlinking system comprising: an external interface configured to receivealerts reporting determined fraud events detected in the externalsystems by the respective at least one fraud detection engine; a storagedevice configured to store determined historical fraud events in adatabase including the received determined fraud events in the alerts; aprocessor comprising hardware configured to provide: an alert classifierarranged to implement a plurality of match methods for detecting linksbetween a received alert from one of the external systems and one ormore stored determined historical fraud events or another received alertfrom another one of the external systems, each match method implementingdifferent matching criteria, the alert classifier thereby generating andoutputting a respective score for each match method representative ofthe extent of matching with one or more identified determined historicalfraud events or another received alert; and a voting engine for applyinga set of weightings to the scores generated by the classifier for eachof the match methods and for determining that there is a link with anidentified determined historical fraud event or another received alertif a combination of the weighted scores exceeds a predeterminedthreshold.
 2. The fraud linking system as claimed in claim 1, whereinthe matching criteria of the plurality of matching methods comprisecriteria defined in relation to specific field types in a receivedalert, selected from a numerical field, a name field and a riskquantifier.
 3. The fraud linking system as claimed in claim 1, furthercomprising a case management sub-system arranged to receive notificationof links determined by the voting engine and to receive feedback from auser regarding validity of a notified link, including an indication ofwhether the notified link comprises a false-positive or a false-negativelinkage, and to forward the received feedback to the voting engine foruse in adjusting the set of weightings.
 4. The fraud linking system asclaimed in claim 3, wherein the voting engine is arranged to adjustweightings in the set of weightings by applying linear or non-linearfunctions to feedback received from the case management sub-system tothereby favour scores generated in the alert classifier by match methodsreliably indicative of valid links.
 5. The fraud linking system asclaimed in claim 4, wherein the voting engine is arranged to maintain aregister of match method performance, using data stored in the registerin the adjustment of weightings, and to update the register according tothe received feedback, making use of register locking to ensure thatupdates due to feedback from more than one user may not be madesimultaneously, thus preserving the integrity of the data stored in theregister.
 6. The fraud linking system as claimed in claim 3, furthercomprising a timer arranged periodically to trigger a process whereby aplurality of records of determined historical fraud events are extractedfrom the database according to predetermined search criteria and passedthrough the alert classifier and the voting engine to identify linksbetween the extracted determined historical fraud events using theplurality of match methods or different match methods, any determinedlinks being then recorded in the database using a unique key to identifythe linked events as a group and notified to the case managementsub-system.
 7. The fraud linking system as claimed in claim 1, whereinthe processor comprising hardware is further configured to provide anadapter for performing one or more functions upon receiving alerts,selected from: normalizing a received alert; alert validation; additionof data, retrieved dynamically from an external database, to a receivedalert; executing a set of logical routines on individual fields of areceived alert to perform validation of fields of the alert to checkthat they satisfy quality tests; executing a set of logical routines toperform transformation of individual fields in a received alert into arequired format or create additional fields which are combinations ofexisting fields; and routing a received alert directly to the alertclassifier without modification.
 8. The fraud linking system as claimedin claim 1, wherein the processor comprising hardware is furtherconfigured to provide an adapter for normalizing the alerts, andwherein: the adapter performs alert validation, and the adapter addsdata to an alert, and the adapter dynamically retrieves data from anexternal database to add to an alert, wherein the processor comprisinghardware is further configured to route alert directly to theclassifier, by-passing the adapter when a condition is satisfied; andwherein the fraud linking system further comprises memory buffers totemporarily hold messages until they can be processed.
 9. The fraudlinking system as claimed in claim 1, wherein: the processor comprisinghardware is further configured to provide an adapter for normalizing thealerts, and wherein the adapter performs alert validation, and theadapter adds data to an alert, and the adapter dynamically retrievesdata from an external database to add to an alert, wherein the processorcomprising hardware is further configured to route a alert directly tothe alert classifier, by-passing the adapter when a condition issatisfied; wherein the fraud linking system further comprises memorybuffers to temporarily hold messages until they can be processed; andwherein the processor comprising hardware is further configured to fetchmessages from one of the memory buffers and to execute a set of logicalroutines on individual fields of each alert to perform validation offields of the alert to check that they meet quality tests.
 10. The fraudlinking system as claimed in claim 1, wherein: the processor comprisinghardware is further configured to notify a case management system oflinks, and wherein the voting engine comprises a function for receivingfrom the case management system feedback of success of each matchmethod, and for adjusting match method weights accordingly, the votingengine is adapted to initialize a plurality of match method weights tobe equal and to vary them according to success of each individual matchmethod in identifying links, and said feedback includes a number offalse positives and a number of false negatives; and wherein saidroutines perform transformation of individual alert fields into arequired format or create additional fields which are combinations ofexisting fields.
 11. The fraud linking system as claimed in claim 1,further comprising a configuration function for configuring at least oneof the components of the fraud linking system, including the alertclassifier.
 12. The fraud linking system as claimed in claim 1, furthercomprising a case management system for transmitting feedback to thealert classifier, and wherein: the processor comprising hardware isfurther configured to notify a case management system of links, thevoting engine comprises a function for receiving from the casemanagement system feedback of success of each match method, and foradjusting match method weights accordingly, the voting engine is adaptedto initialize a plurality of match method weights to be equal and tovary them according to success of each individual match method inidentifying links, and said feedback includes a number of falsepositives and a number of false negatives.
 13. A non-transitory computerreadable medium comprising software code for performing the alertclassifier and the voting engine of a fraud linking system of claim 1when the processor comprising hardware is a digital processor.
 14. Thefraud linking system as claimed in claim 6, wherein the processorcomprising hardware is further configured to insert into the database anew database record comprising the unique key of the alert, the uniquekey(s) of one or more alerts and a flag to indicate that the alerts arelinked.
 15. The fraud linking system as claimed in claim 7, wherein thealert adapter translates received alerts so that they contain fourfields including a unique identifier, name, date of birth and averagetransaction size.
 16. The fraud linking system as claimed in claim 1,wherein the match methods include fuzzy text matching to find possiblecommon sources based on descriptive attributes selected from name,address, occupation; or quantitative attributes selected from Euclideandistance, Mahalanobis distance, transaction size, transaction frequency.17. The fraud linking system as claimed in claim 1, wherein differentreceived alerts indicate detected events associated with differentpersons.
 18. The fraud linking system as claimed in claim 17, whereinthe different received alerts indicate detected events associated withone of different persons and a same person, respectively.